Exchange Server 2010 : Edge Transport and Messaging Security (part 1)

Implementing Edge Transport Server

The Edge Transport server role in Exchange Server 2010 provides a secure SMTP gateway for all incoming and outgoing e-mail in an organization. As an SMTP gateway, the Edge Transport server's primary role is to maintain message hygiene, which includes anti-spam and antivirus filtering. You also can use the Edge Transport server to apply messaging policies to messages that are sent to the Internet.

When planning to deploy Edge Transport servers, consider the following factors:

• You cannot install the Edge Transport server role along with any other Exchange Server 2010 server role. The Edge Transport functions require a very separate level of security and must be separated from your Exchange organization. To provide increased security, you must install the Edge Transport server role on a separate computer, which can be virtual or physical.

• Edge Transport servers should be installed in the perimeter network and should be physically secure and well separated from servers in the internal network.

• The computer should not be a member of an internal Active Directory domain.

---

Note: You should not install the Edge Transport server role on a computer that is a member of the internal Active Directory domain, but you can install it in a perimeter Active Directory forest. Microsoft IT and other large companies have a dedicated Active Directory domain for servers in the perimeter network. This makes security updates and other maintenance/management easier than when you're dealing with non-domain-joined computers.

---

1. Considering Firewall Ports

Because the Edge Transport server role is installed in a perimeter network and thus is directly connected to the Internet, you should also plan to place a firewall between the Internet and your Edge Transport server to increase protection. This firewall should be configured to open certain ports.

This section is about what network ports you should open in the firewall that is between the Internet and the perimeter network (external) and the perimeter network and the internal corporate LAN (internal), as described in Table 1. You can take this as the minimum number of ports you should open, but remember that you can also configure the Edge Transport to use network ports other than those listed here.

The table includes only the Edge Transport server role.

2. Planning and Configuring Edge Synchronization

The Edge Transport server does not use Active Directory to store its configuration information; instead, Edge Transport servers use Active Directory Lightweight Directory Services (AD LDS) to store this data. AD LDS is the successor of Active Directory Application Mode (ADAM), a service that was available in Windows Server 2003.

2.1. About AD LDS

AD LDS is a special mode of the AD DS that stores information for directory-enabled applications. AD LDS is an LDAP-compatible directory service that runs on servers running the Windows Server 2008 or Windows Server 2008 R2 operating system. AD LDS is designed to be a stand-alone directory service. It does not require the deployment of DNS, domains, or domain controllers; instead, it stores and replicates only application-related information.

Before you can install the Edge Transport server role, you must install the AD LDS server role on the same Windows Server 2008 computer that will host the Edge Transport role. This is because AD LDS stores configuration data for your Edge Transport server role. During Exchange installation, AD LDS is then configured automatically. The following types of information are stored in AD LDS:

• Schema

• Configuration

• Recipient information

The AD LDS database is stored in the <Exchange_Install_Path>\TransportRoles\data\Adam directory.

The AD LDS instance does not need much administration because all the information that it contains is synchronized using Edge synchronization from the Active Directory instance that holds all of the Exchange organizational configuration data and information about mail-enabled objects. Even if the database is lost, you just start EdgeSync again and the database will be newly created.

However, always consider that the database does not include all configurations and settings, so it is best practice to back up the Edge server configuration using the ExportEdgeConfig.ps1 script.

2.2. Edge Synchronization

Edge synchronization, or EdgeSync, is a process that replicates information from your internal Active Directory to the AD LDS located on the Edge Transport server.

Because Edge Transport servers are not joined to the internal Active Directory domain, they cannot directly access the configuration or recipient information that is stored in Active Directory.

You can deploy Edge Transport servers without using EdgeSync, but using EdgeSync can decrease the effort needed to administer the Edge Transport servers. Active Directory contains much of the configuration information required by the Edge Transport server. For example, if you configure accepted domains in Exchange Management Console for all Hub Transport servers centrally, these accepted domains are replicated automatically using EdgeSync to the Edge Transport servers. Every Edge Transport server needs its own Edge Subscription to synchronize with Active Directory.

To enable any filtering or transport rules that are based on recipients, you must implement EdgeSync to replicate the recipient information to AD LDS.

2.2.1. EdgeSync Replication

After you enable Edge Synchronization, the EdgeSync process establishes a point of synchronization between one Hub Transport server in the Active Directory site that was selected and the Edge Transport server, and synchronizes configuration and recipient information between Active Directory and AD LDS.

Even though EdgeSync is very similar to Exchange Server 2007, in Exchange 2010 EdgeSync keeps track of synchronized information and only synchronizes the changes since the last replication cycle. Of course, this is much more efficient than EdgeSync in Exchange 2007.

During synchronization, EdgeSync replicates the following data:

• Accepted domains

• Send connectors

• Hub Transport servers list (for dynamic connector generation)

• Recipients (one-way hashed)

• Safe senders, safe recipients, and blocked senders (one-way hashed)

• Domain Secure List (such as the TLSSendDomainSecureList and TLSReceiveDomainSecureList properties)

Some configuration settings have to be made on the Edge Transport server role level because these configurations are not replicated using EdgeSync. The following list includes all areas that you need to configure for every Edge Transport server or use Edge Transport cloning to share a single configuration between all Edge Transport servers:

• All Edge Transport server settings (external or internal DNS Lookups, Log Settings, Limits, and so on)

• Exchange Product Key

• Anti-spam settings

• Receive connectors

• Transport rules

• Digital Certificates and Exchange services enabling digital certificates to secure communications

2.2.2. How does EdgeSync Work

To establish Edge Synchronization between an Edge Transport and Hub Transport server, you need to follow these steps:

If you want to perform EdgeSync on your Edge Transport server, you should consider the following areas before creating the Edge subscription file:

• An Edge Transport server needs a fully qualified domain name (FQDN) configured.

• You must register the FQDN with your DNS server.

• The FQDN must be resolvable and reachable from the Hub Transport servers in the site where you add the Edge subscription file.

• EdgeSync and the Connectors use the computer certificate of the Edge Transport server, so make sure you've already installed the correct certificate (for example, that supports TLS if required).

You create an Edge subscription file by using the New-EdgeSubscription cmdlet in EMS started with Run as Administrator. The default EMS will not provide sufficient permissions to create an edge subscription. This will create an XML file, as shown in Figure 7-1.

As you can see, the sample Edge subscription file includes certain information such as the Edge servers' FQDN, the Edge server's public certificate, the default SSL port that is used for AD LDS, and the server's Exchange version. You have to use the Edge subscription file on a Hub Transport server within 1,440 minutes or the XML will expire.

After you create the Edge subscription file, you need to copy it to a Hub Transport in the Active Directory site that you want to link the Edge Transport server to. On the Hub Transport server, use the New-EdgeSubscription cmdlet to import the Edge subscription file.

Be aware that you cannot pass the filename directly to the cmdlet—you need to pass the data string, as shown in Figure 2. This is because of remote Windows PowerShell. Since the script is not running locally, you can't give a local path but have to pass the file data in the cmdlet.

After the Edge subscription file is imported to the Exchange configuration, the EdgeSync replication process starts automatically. The default port for synchronization is port 50636 as defined in the Edge subscription file.

To change the default EdgeSync communication port you can use the ConfigureAdam.ps1 script located in the <Exchange_Install_Path>\Scripts folder. For example, if you want to change the communication port to 50222, run .\ConfigureAdam.ps1 –Sslport:50222 with EMS.

The first Hub Transport in the Active Directory site where you created the Edge subscription that notices the subscription seizes the lease and will use the Microsoft Exchange EdgeSync service to start the synchronization with the Edge Transport server. This Hub Transport server will keep the lease until it goes offline or is otherwise unable to service the subscription which will then result in the next Hub Transport available in the Active Directory site seizes the lease.

If you like to force immediate replication, you can use the Start-EdgeSynchronization – TargetServer <EdgeTransportName> -Server <HubTransportName> cmdlet, which will trigger the replication and show you some information about recent changes in Active Directory.

Alternatively you can make sure that the EdgeSync process finished successfully by running the Test-EdgeSynchronization –FullCompareMode cmdlet on a Hub Transport server in the connected Active Directory site that will compare Active Directory with the AD LDS on all Edge servers that are subscribed to the Active Directory site to make sure they are synchronized correctly. You will receive detailed information as output, as shown in Figure 3.